HTTP is a type of “single connection per single payload” protocol. That is, whenever data is transferred in the payload of a packet, and thereafter received, the connection is shut down. By design of the HTTP protocol, a connection is setup and made, a request (e.g., an HTTP request) is transmitted from a client device (client) to a server computing system (server), a response (e.g., an HTTP response) from server is received at the client, and the connection is closed. The request may be to request data from the server (e.g., an HTTP “GET”), for example, an html page at a designated uniform resource identifier (uri or url); or the request may be to transmit (send, forward, communicate, etc.) data to the server (e.g., an HTTP “POST”). The response from the server is typically to send the html page located at the uri specified with the response or to receive the data sent by the client. The payload of an HTTP packet contains the data (e.g., the uri, posted data, or html page).
There are a couple of exceptions to this. In one extension to HTTP, a multi-part response to an HTTP request allows more than one response to be received for a single connection. However, the connection is still is effectively one HTTP request per connection, because a client cannot interpret and re-send data, based on the response(s), without making another connection to the server. In addition, some browsers, such as Internet Explorer, which support multiple payloads, include a size limitation on certain elements of the multi-part message.
Comet style programming, which provides a web application model, improves or eliminates connection setup time by making the connection ahead of time, and keeping the connection open, in anticipation that data that will be sent to a browser. This model anticipates that a server will push data to a browser, without the browser (or other application executing on the client) explicitly requesting it using an HTTP request. It is a type of “push” protocol. But even these connections eventually have to be closed.
See, for example, http://en.wikipedia.org/wiki/Comet_(programming).
Use of HTTP connections is not efficient due to the overhead on both the client and the server in setting up and closing out the connections. Use of such connections also introduces latency in communication between the client and server, because each connection has to be established before a request can be made. Also, there is no provision for providing state information across connections, as each connection is independent of another. Hence, there is no support for persistency or state-full information across connections, unless duplicate state information is passed in a subsequent request, or state identifiers are used.
Other single payload per single connection type protocols have similar deficiencies.